IBIS Macromodel Task Group Meeting date: 24 March 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 17 meeting. Michael moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Discussion on "Gap in IBIS for sampling with statistical mode AMI models": Hansel reported that he is progressing on an initial BIRD draft. He is folding in some changes from various discussions. He expects to have a draft for review in the next couple of weeks. Hansel noted one question he wanted to submit to the group. Currently there is no mechanism for the model to share the sampling position of the main cursor with the EDA tool. The model has to tell the EDA tool where to sample. Hansel said that sampling point can be with respect to a step response or a pulse response, but not an impulse response. He asked if the group preferred to use a step or pulse response. Arpad noted that the IBIS specification currently only defines an impulse response input to the AMI functions. He said we can't talk about a response that is not passed into the model, so the proposal would have to be very careful about how these responses were defined. Ambrish asked Hansel to capture his question in an email for ATM to consider. Hansel took an AR to send an email detailing his question. DDR Clock Forwarding: A straw poll on whether Fangyi's proposal was ready to submit to the Open Forum as a BIRD was scheduled for this meeting. Walter requested that we defer the vote and continue discussion. He said adding a new function signature (AMI_GetWave2()) was a big step and should be done with great thought and consideration of any alternatives. He said he preferred to use the clock_times vector as an input to the DQ AMI_GetWave() to accomplish the same thing. He said he needed to understand what prevented that solution from working. Ambrish noted that he concurred with Walter. He said his team had demonstrated that a clock_times vector input was sufficient. He expressed the concern that this proposal might unnecessarily complicate the flow, and he wasn't sure the need for it had been demonstrated. Fangyi said that only having the clock_times vector to represent forwarding the clock will not work for the Phase Interpolator. If you don't have the actual DQS waveform, then you can't model the behavior of the PI. The DQS waveform is needed, and that's why they had proposed AMI_GetWave2(). Michael noted that he concurred with Walter (on deferring a vote), for a different reason. He said that his organization had two groups that had been independently approaching this issue. One group co-proposed Fangyi's method, and the other team had a different perspective. Michael asked for delay of a week or two so those teams could get in sync and potentially incorporate both perspectives. Arpad noted that, in terms the straw poll, just because we submit a BIRD to the Open Forum doesn't mean that someone else couldn't submit a competing BIRD. He asked if we needed to delay this proposal from being submitted, and if we preferred to hash things out and come up a single BIRD. Walter agreed that nothing prevents Fangyi from submitting his proposal. An ATM vote to confirm that we recommend a BIRD isn't necessary, but we tend to want to come to agree- ment in ATM before submitting a BIRD to the Open Forum. If there are any disagreements in the Open Forum, then discussion comes back to ATM anyway. Radek said a limited delay and discussion of any specific questions from Michael made sense, but he said that passing additional data through strings was an inferior solution. Ambrish asked if he could quantify how inferior. Arpad asked about the use of clock_times as an input. He asked what the source of the clock ticks would be. It currently comes from another .dll (the DQS Rx), but couldn't that other .dll have the PI model so it could put its strobe output in the clock_times vector? Fangyi said the PI is in each DQ Rx. It could be different from DQ to DQ, so you can't generate it in the model for the DQS that could be shared by multiple DQs. Walter said there were two ways to generate clock ticks. The EDA tool could look at a DQS Rx input waveform and determine crossings and figure out the clock ticks. Alternatively, the DQS input waveform goes through the DQS model's AMI_GetWave() and the output clock_times array contains the clock ticks. Referring back to Fangyi's presentation on this proposal, Walter said several slides had presented an overview of the PI, its characteristic equation, tau1 tau2, etc., but that the vin and vout weren't explicitly defined. He said we need to understand, given the values and expected ranges of these parameters, the magnitude of the effect we are trying to capture. We need to convince ourselves we need a new function signature. Fangyi reviewed the PI portion of his presentation, slide 6 in particular. He noted that vin is defined as the DQS output waveform (the DQS signal). tau1 and tau2 are two different delay times. The input is delayed by tau1 and by tau2, and then a weighted sum of the two is computed according to the value of n. Fangyi noted the "Ideal input" and "Ideal output" figures on slide 6. The Ideal output showed different waveforms you'd get by varying n. The "Real Output" figure shows a more realistic example of how the output waveforms would vary with n given a non-ideal input waveform. If you use the output waveform to drive the clocking, then different values of n give you a different delay in the crossing time. Ambrish asked if this was delving too far into how a model is implemented. Walter said that a PI introduced a delay of the zero crossing of the waveform. Fangyi agreed, roughly speaking. Walter said if the model had clock ticks it could pick a delay value based on those clock ticks to get the sampling location right. Why would Fangyi's proposed method give a different answer than a model adjusting based on input clock ticks? Arpad said the PI works on the DQS waveform, which we don't have any more if using clock ticks. Walter said the PI is a kind of CDR that works by introducing delay. Fangyi said Walter's model would be treating the delay as continuous and choosing the best delay. Fangyi said the discretized delay values depend on the shape of the waveform. Curtis said he thought Fangyi was stating that the model couldn't even know what discrete delay variations would be available by changing n if it didn't know the shape of the waveform. Fangyi agreed. Walter noted that the hardware could only sweep n and choose the best value. He asked what the magnitude of the error bound would be for using clock ticks instead of the actual waveform. He agreed that the value of n chosen in simulation might not be the value hardware would choose, but what was the magnitude of the error in actual delay value? Walter proposed a 6GHz example with a PI with N=32. Since the UI was approx. 160ps, with N=32 you could get 160/32 = approx. 5ps resolution. Fangyi said this uniform spacing assumption was not correct, as the spacing of the discrete steps depended on the shape of the waveform. Walter said he was trying to get a handle on the magnitude of the error. Michael asked if a buffer designer would have to specify a range of n values for which their design should work? Walter said this was a different issue. DDR4, for example had constraints on matching the electrical lengths of the DQs. DDR5 is less constrained in this regard. So every DQ can be trained independently. The controller could set that skew by choosing any value of n it wanted for each DQ. The controller can choose from the entire range of 0 to N to best match the delay for each channel. Fangyi referred back to the "Ideal Output" figure on slide 6. He noted that if you drew a horizontal line through that figure at any level, you really only had two different delays that were realizable, even though you stepped through all N+1 values of n. There is no delay in the middle of that range that you can realize with an ideal waveform, for example. You don't know what discrete delay values are available without the actual DQS waveform. Arpad said he would summarize Fangyi's statements and the horizontal line on the "Ideal output" example as follows: There may be plenty of values of n to sweep through, but the actual crossing delays available might be fewer. In this case there were only two values available and no value of delay between the two of them was realizable. In a real case with a waveform with non-ideal finite slopes, varying n would provide more discrete values of delay in the middle of the range. Fangyi noted that slicer sensitivity to slew rate is another reason to pass the DQS waveform into the DQ Rx model. Referring to the block diagram of the Controller DQ Rx Model (slide 5), he pointed out the Slicer block and asked how you can model the slicer's sensitivity to slew rate without the DQS waveform? - Bob: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Hansel to send an email to ATM about his step vs. pulse response question. ------------- Next meeting: 31 March 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives